cpupools: avoid crashing if shutting down with free CPUs
in fact, before this change, shutting down or suspending the
system with some CPUs not assigned to any cpupool, would
crash as follows:
(XEN) Xen call trace:
(XEN) [<
ffff82d080101757>] disable_nonboot_cpus+0xb5/0x138
(XEN) [<
ffff82d0801a8824>] enter_state_helper+0xbd/0x369
(XEN) [<
ffff82d08010614a>] continue_hypercall_tasklet_handler+0x4a/0xb1
(XEN) [<
ffff82d0801320bd>] do_tasklet_work+0x78/0xab
(XEN) [<
ffff82d0801323f3>] do_tasklet+0x5e/0x8a
(XEN) [<
ffff82d080163cb6>] idle_loop+0x56/0x6b
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Xen BUG at cpu.c:191
(XEN) ****************************************
This is because, for free CPUs, -EBUSY were being returned
when trying to tear them down, making cpu_down() unhappy.
It is certainly unpractical to forbid shutting down or
suspenging if there are unassigned CPUs, so this change
fixes the above by just avoiding returning -EBUSY for those
CPUs. If shutting off, that does not matter much anyway. If
suspending, we make sure that the CPUs remain unassigned
when resuming.
While there, take the chance to:
- fix the doc comment of cpupool_cpu_remove() (it was
wrong);
- improve comments in general around and in cpupool_cpu_remove()
and cpupool_cpu_add();
- add a couple of ASSERT()-s for checking consistency.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Tested-by: Juergen Gross <jgross@suse.com>